An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

How long the paid apps agreement takes ? im not sure what's going on, I have all active my bank account etc, I added well all the products etc, but still says processing, I ask for help, and no one hasn't answer anything yet, I look on YouTube I didn't find anything, I ask Ai and just says I need to fking wait !! im so tired of waiting desperate also bc I worked so much on this and is crazy that noe apple is taking so much time not sure if this is real or what's going on!!

Hi App Review team, I'm posting here as a last resort after7 weeks with no movement and 4 unanswered support requests. I'm about to lose my launch window next week and I need someone at Apple to look at this. The situation: App: BMH Themes — App ID 6763770421 — Bundle ID com.bringmedinahome.bmhthemes Version 1.0 (Build 24): reviewed and APPROVED, currently "Ready for Distribution". In-app purchases: 904 are APPROVED, but 1,134 have been stuck in "Waiting for Review" for 7 weeks. The 1,134 stuck items are the exact same type as the 904 already approved — so this is clearly not a content issue. None of the 1,134 show any rejection or "Developer Action Needed" message. Nothing is pending on my side. I have submitted 4 support requests over the past weeks. None received a substantive response. Why this is urgent: My company is now legally registered, my VAT number is being issued, my business bank account is active, and my full marketing campaign is finalized for a launch next week. I cannot launch with 1,134 of my products frozen — releasing a half-empty catalog would waste the entire launch. These stuck in-app purchases are the ONLY remaining blocker. My request: Could someone please check whether these 1,134 in-app purchases are correctly queued, confirm whether there is an internal processing issue, and escalate to the App Review / in-app purchase team? The app is already approved — only these items are stuck. Thank you very much for any help.

Hello everyone, I would really appreciate some advice regarding an App Review rejection under Guideline 1.2 because I’m unsure what the best next step is. The review notes included the following statement: “Since this app’s primary functionality is not permitted on the App Store, it would be appropriate to submit a new app with functionality that follows the App Review Guidelines. Resubmitting the app will result in the same or additional App Review Guideline violations.” This wording makes me unsure whether I should submit a new build with the changes I have made or continue discussing the issue through the Resolution Center. The app was rejected because App Review considered its primary purpose to be random or anonymous chat. However, I believe there may have been a misunderstanding about how the application actually works. The application is not a private messaging app, nor is it designed to let people freely chat with strangers. The concept is closer to a discussion that takes place on a user’s profile, similar to two people having a conversation in the comments section of a social media platform. Other authorized users can read those conversations and react to individual messages, so the conversation itself becomes the content rather than functioning as a traditional direct message. Users are never anonymous. Every account has a persistent identity, including a username, profile picture, verified email address, and profile information. The application also includes reporting, blocking, restricting, and moderation features. Communication is intentionally very limited. Users cannot simply message another user whenever they want. Even after all other requirements are met, a user can send only one initial message. The recipient then has 24 hours to decide whether to reply. If the recipient chooses not to reply, the conversation never begins, the thread is automatically moved to the archive after 24 hours, and the sender cannot continue contacting that user. They cannot send another initial message or repeatedly attempt to start a conversation. A conversation can only continue if the recipient voluntarily chooses to reply. Originally, every account was private by default, although users could choose to make their profile public. During App Review, I temporarily made the review accounts public because I wanted the reviewer to be able to explore the application more easily without needing multiple test accounts. Looking back, I now believe this may have unintentionally made the application appear much closer to a stranger chat experience than it was actually designed to be. Another detail that may not have been visible during review is that the reviewer reached the message composition screen but did not actually submit a message. (I saw it on screenshots they attached) If they had submitted it, they would have seen that the initial message does not immediately become an active conversation. Instead, it first enters a pending state where the recipient decides whether to accept it by replying. Without the recipient’s voluntary participation, no conversation is created. After receiving the rejection, I decided to redesign this part of the application to make the communication model even more restrictive. I completely removed the ability for users to have public profiles. Every account is now permanently private. Before any interaction is possible, a user must first send a follow request, and the recipient must explicitly accept that request. Without an accepted follow request, it is impossible to send the initial message. I also removed the discovery feature that could resemble random user discovery and replaced it with standard user recommendation cards similar to those used by many social networking applications. In addition, I implemented follow request rate limiting so users cannot rapidly send large numbers of follow requests. As a result, users can now interact only after mutual consent has already been established through an accepted follow request, and even then, communication is still limited to a single initial message that requires the recipient’s voluntary reply before any conversation can exist. My question is this: Given these changes, would you recommend submitting a new build for review despite the statement that “Resubmitting the app will result in the same or additional App Review Guideline violations,” or would it be better to continue discussing the issue through the Resolution Center first? (Some why they don't reply me at all) If anyone has dealt with a similar Guideline 1.2 situation, I would sincerely appreciate your advice on how you would proceed. Thank you very much for your time

Hi everyone, I’m looking for guidance because I’m struggling to understand an App Review decision. My app, The Leaf Cellar, is a cigar companion app that includes cigar image scanning, humidor management, cigar journals, tasting notes, lounge discovery, and recommendations. My app was rejected, yet there are multiple applications currently on the App Store with substantially similar functionality, including: Ember: AI Cigar Companion (released this year) My Humidor – Cigar Journal Humidor Journal Pro ACJ These apps continue to receive updates and remain available on the App Store. I’m trying to understand what materially distinguishes my implementation from theirs. If Apple considers my app to violate a specific guideline, I would appreciate understanding what objective difference exists between my app and these already approved apps. Has anyone experienced a similar situation where comparable apps were approved but theirs was rejected? Were you able to resolve it through App Review or the App Review Board? Any advice on how to present the strongest case would be greatly appreciated. I’m not looking for speculation or opinions. I’m looking for a clear explanation of how the App Store Review Guidelines are being applied in this case, especially given that a competing app with substantially similar functionality was approved and released this year. From my perspective, the current outcome appears inconsistent, and I would appreciate any insight from developers who have successfully navigated a similar situation. Thank you.

How can Apple deny my appeal and not approve my app for tobacco when multiple apps like these are on the store?

My app has been stuck in “Waiting for Review” since June 23, 2026. It has now been 10 days without moving to “In Review.” I have already contacted App Review through App Review Status, but I have not received an update yet. I also checked App Store Connect and do not see any missing metadata, Resolution Center messages, App Privacy issues, Age Rating issues, Export Compliance issues, or missing Review Notes. Is anyone else currently experiencing unusually long “Waiting for Review” times? Also, is there anything else I should check on my side before contacting App Review again?

Hello everyone. I hope the Apple team sees my message. I submitted my app for review on June 15th. It's been in the "Waiting for Review" status since then. The app doesn't have any complex structures. No authorization (except for GameCenter), no encryption, etc. It's written in Swift, the native language, and is iOS-exclusive. I've contacted support three times, submitted a request for expedited review, and responded to the emails that arrived confirming my request, but there's been no response, even though the messages indicated a response within 24-48 hours. Apps are successfully submitted to the testing environment. I feel like I'm being ignored. Please help, I'm really looking forward to the App Store release due to the planned events. If anyone has had a similar situation, please share what helped and how long it took for your app to be reviewed, so I can understand how much longer I need to wait.

Guideline 1.4.3 rejection for a cigar journal app — multiple apps with identical functionality are live on the App Store Hi all, My first submission (a cigar humidor/tasting journal app) was just rejected under Guideline 1.4.3 (Safety – Physical Harm) for "content or features related to the use of tobacco... products." The rejection states the app's concept is "not appropriate because it is focused on these products or activities." The issue: my app doesn't sell tobacco, doesn't facilitate purchasing it, and doesn't encourage consumption any more than a whiskey-tasting log encourages drinking. It's a personal tracking/journal tool — users log cigars they already own, rate them, track humidor inventory, etc. There is no e-commerce, no social sharing of consumption, no promotional content. There are currently multiple apps live on the App Store with functionally identical (in some cases nearly indistinguishable) feature sets: My Humidor – Cigar Journal — https://apps.apple.com/us/app/my-humidor-cigar-journal/id6639582700 Humidor Journal Pro — https://apps.apple.com/us/app/humidor-journal-pro/id6751737114 Ember: AI Cigar Companion — https://apps.apple.com/us/app/ember-ai-cigar-companion/id6761503587 Whiskey and Cigar Pairing — https://apps.apple.com/us/app/whiskey-and-cigar-pairing/id6762530184 Cigarbase: AI Cigar & Humidor — https://apps.apple.com/us/app/cigarbase-ai-cigar-humidor/id6761301449 Leaf Enthusiasts — https://apps.apple.com/us/app/-/id6757314729 Cigar Journal & Tracker: Puro — https://apps.apple.com/us/app/cigar-journal-tracker-puro/id6760948482 ASHD – Cigar Social — https://apps.apple.com/ca/app/ashd-cigar-social/id6759581213 All of these are humidor/cigar journaling or social apps built around cataloging and tracking tobacco products — the exact category my app was rejected for. Several even use AI companion/recommendation features, which is a superset of what my app does. Full rejection text for reference: Guideline 1.4.3 - Safety - Physical Harm Issue Description: The app includes content or features related to the use of tobacco, nicotine-related, or vaping products, including but not limited to cigarettes, pipes, hookahs, or e-cigarettes. Apps with content or features related to consuming tobacco are considered to encourage the consumption of tobacco. Since these products pose a risk of physical harm to users, it is not appropriate to encourage their use. Next Steps: Your app's current concept is not appropriate because it is focused on these products or activities. It would be appropriate to revise the app or submit a new app that is not focused on these products or activities. My questions for the community: Has anyone successfully appealed a 1.4.3 rejection for a tobacco tracking/journal app (as opposed to a marketplace or vaping-hardware app) by citing comparable live apps? Is there a meaningful distinction reviewers are drawing between "journal/inventory" apps and something else, and if so, what specific wording or framing helped get it approved? Is the right move to reply in App Store Connect citing these examples, or file a separate appeal with the App Review Board? Any input from developers who've navigated this — especially in adjacent categories like whiskey, wine, or other regulated-but-legal-consumable tracking apps — would be hugely appreciated. This is my first submission, so I want to handle the response the right way rather than burning an appeal on the wrong approach. Thanks in advance.

Hello, I'm evaluating Foundation Models announced at WWDC 2026 and have a question regarding App Store distribution. My understanding is that Foundation Models are only available on supported devices and operating system versions. For apps that rely on Foundation Models as their primary functionality (rather than offering AI as an optional feature), I'm trying to understand the recommended distribution strategy. Currently, iOS provides Required Device Capabilities to prevent users from installing apps that require hardware features such as GPS, ARKit, or NFC. However, I couldn't find an equivalent Required Device Capability for Foundation Models. I also couldn't find a way to limit App Store availability by supported device models. My questions are: What is the recommended way to distribute an app whose primary functionality depends on Foundation Models? Is there currently any supported mechanism to prevent users with unsupported devices from downloading such an app? Is Apple planning to introduce a Required Device Capability (or a similar App Store filtering mechanism) for Foundation Models before public release? Without such a mechanism, users may be able to install the app successfully but then discover that its primary functionality is unavailable on their device. I'd appreciate any guidance on the recommended approach. Thank you.

Hello, I recently received a Pending Account Termination Notice for my Apple Developer Program account. The notice refers to section 3.2(f) of the Apple Developer Program License Agreement and says the account may have been involved in dishonest or fraudulent activity, including possible concept or feature switching after review. I have already submitted an appeal to the App Review Board. The difficult part is that the notice does not mention a specific app, bundle ID, version, or behavior. I have multiple apps under the account, so I am trying to identify what may have caused the issue. During my review, I found one possible area: one app uses different API server endpoints depending on the user’s IP region or network location. This was only done to improve connection speed and reliability. For example, overseas users may connect to an overseas server because access to Mainland China servers can be slow or unstable. The app is not intended to show different features, menus, content, or user flows across those servers. The server routing only changes the API endpoint for performance reasons. It is not used to detect App Review users or hide any functionality. I also have several other apps under the same developer account. These apps were previously reviewed and approved through the normal App Review process, and I did not intentionally implement any mechanism to mislead App Review, hide features, or change the app concept after approval. Because the notice applies at the account level but does not identify a specific app, bundle ID, version, or behavior, I am having difficulty understanding what exactly triggered this enforcement action. I am willing to review and correct any issue, but I need to understand whether the concern is related to regional server routing, a specific app implementation, App Store metadata, server-side configuration, or something else. My questions are: Can regional API routing based on IP or network location be misunderstood as dynamic content or feature switching after review? What kind of documentation or evidence is most helpful to provide in an appeal to show that different server endpoints provide the same app experience? Should I provide side-by-side API responses, backend configuration screenshots, and screen recordings from different regions? If the termination notice does not identify a specific app, is there any way to request clarification about the app, bundle ID, version, or behavior that caused the concern? Is there any recommended way to document multiple apps in an appeal when the notice is account-level rather than app-specific? I understand that nobody here can make a decision on my account. I am only looking for general advice on how to clearly explain this type of server routing, how to review multiple apps under the account, and what evidence is usually useful. Thank you.

Hi everyone, I want to start by saying that I genuinely appreciate the work Apple’s reviewers, support teams, engineers, and testers do. The volume and variety of apps they have to evaluate must be enormous, and I understand why Apple has to be careful about protecting users and the App Store from deceptive or unsafe apps. I’m posting because I’m looking for guidance from anyone who has navigated a Pending Account Termination appeal. This is for my first iOS app submission. The app is a location-based social planning app for adults to create and join nearby plans. It is a real product, not a template/spam app, and I have been trying to make review as straightforward as possible. Timeline: Submitted / Ready for Review: June 10, 2026 In Review: June 15, 2026 I also had a TestFlight external testing review delayed for about a week I submitted support requests and an expedited review request, but did not receive any responses 19 days after submission, I received a Pending Account Termination notice alleging dishonest or fraudulent activity under the Developer Program License Agreement I have submitted an appeal to the App Review Board. The web page confirmed receipt, but I did not receive a separate email or appeal case ID. I also opened a Developer Support case just to confirm the appeal is in the queue. I want to be very clear: the app is honest and there was no intent to evade App Review. Because the app depends on nearby user-generated plans, I had created demo/test data and a review account so reviewers would not see an empty app in a location with no users. After TestFlight external testing was approved and before sharing the public link with real testers, I removed the synthetic test/demo data so production would contain real user activity only. I have already taken corrective steps: Removed automatic review/demo reseeding behavior from the backend Removed synthetic demo users and content related to them from production Current production data is real user data only I understand Apple has to protect users and the App Store from deceptive apps, spam, and fraud, and I appreciate how difficult that job must be at scale. I’m trying to handle this carefully and respectfully. For anyone who has been through a Pending Account Termination appeal: Is it normal not to receive an appeal case ID by email? How long did the App Review Board take to respond? Is there any appropriate way to provide clarifying information after submitting the appeal, or should I wait for Apple to reply? Thank you for any guidance.

Hello, Our app, Cloudkeep Rivals, was rejected under Guideline 4.3(a) - Design - Spam. The App Review message says that the app appears to share a similar binary, metadata, and/or concept with apps previously submitted by a terminated Apple Developer Program account. The reviewed version was 1.0 (202606172035), with review date June 25, 2026, and Submission ID a03a3146-51b2-4440-967b-2326018fb06b. We are trying to understand what exactly triggered this rejection. We have asked App Review several times whether the issue is related to the build/binary, metadata, the game concept, similar heroes/characters, or a possible association with a terminated account. Unfortunately, the replies we receive appear to be mostly the same copy-pasted message, without any specific clarification about which part of the app is considered problematic or what exactly we need to change. We also tried to use the Contact Us / support channels, but we have not received a meaningful response to our support messages or emails. We have now been waiting for about one month without a clear answer. Has anyone experienced a similar Guideline 4.3(a) rejection and managed to resolve it? Is there any effective way to get a more specific explanation from App Review or reach the correct escalation path? We are not trying to flood support or dispute blindly. We simply want to understand the exact issue so we can either fix the problematic part or provide the correct explanation/evidence. Thank you.

Hi, I'm having a problem because my app stuck in "waiting for review" status since Friday (June 26th). Today is the fifth day we've been waiting for Apple to review the app. We had an app lunch scheduled for today and are stuck with no information. We contacted Apple via the standard contact form and requested expedited app review, but unfortunately, nothing has changed; we haven't received a response to our messages. The app is still "waiting for review." What should I do? Is there another way to contact Apple to expedite the review, or at least get information about the review date? App Name: Genie Vault App ID: 678469924

Hello everyone. I hope the Apple team sees my message. I submitted my app for review on June 15th. It's been in the "Waiting for Review" status since then. The app doesn't have any complex structures. No authorization (except for GameCenter), no encryption, etc. It's written in Swift, the native language, and is iOS-exclusive. I've contacted support three times, submitted a request for expedited review, and responded to the emails that arrived confirming my request, but there's been no response, even though the messages indicated a response within 24-48 hours. Apps are successfully submitted to the testing environment. I feel like I'm being ignored. Please help, I'm really looking forward to the App Store release due to the planned events. If anyone has had a similar situation, please share what helped and how long it took for your app to be reviewed, so I can understand how much longer I need to wait.

We get a message that says that our software submission has been approved. Some 10 minutes later, I go there and then find out that it has been deliberately removed by somebody at Apple, Inc again. Right, again... I don't know who is doing it. This is the 4th sabotage incident this year. I have sent a message by clicking on Contact Us. Every time I make an inquiry, a lady replies and says that she will have somebody contact us. But we never receive a followup. I don't know who is doing it. We definitely don't appreciate this type of harassment or sabotage by Apple, Inc. because we have to go there every time they approve our submission. This is a total waste of time. And it's nothing but stupid. They do it whether it's a new software submission or an update. They do it whether the development platform is iOS or macOS. No, we never use manual release.

Hi everyone, I'm encountering an issue with App Store Connect when using a beta version of Xcode and macos. Environment macOS: macOS Golden Gate Beta 27.0 Xcode: Version 27.0 beta 2 (27A5209h) Flutter: 3.41.9 App Store Connect: Production Issue I built my Flutter iOS application using the latest Xcode beta. The archive completed successfully. The build uploaded to App Store Connect without any errors. The build finished processing successfully. The build was available in TestFlight. However, when I tried to add the build to an App Store version and clicked "Submit for Review", App Store Connect displayed an error indicating that builds created with a beta version of Xcode cannot be submitted for review.

Hi Apple Developer Team / Community, I am seeking guidance regarding a difficult distribution issue for our company’s internal iOS application. Our app, FORTIS HRM, is an internal Human Resource Management application used exclusively by employees of FORTIS GARMENTS LTD. It handles attendance, leave requests, approvals, employee directory access, and other HR-related operations. The app is not intended for general public use. Background We initially submitted the app as a public app on the App Store. The app was rejected by App Review for public distribution, since it is intended only for internal employee use and is not suitable for general public users. Based on that, we switched to Apple Business Manager (ABM) / Custom App distribution as a more appropriate solution. The app was reviewed and approved under the custom app distribution path and marked ready for distribution. Unfortunately, our Apple Business Manager enrollment failed repeatedly due to organization verification issues, and our organization was eventually removed from ABM. Since ABM became unavailable, we applied for Unlisted App Distribution. Apple Developer Support informed us that custom apps cannot be converted to unlisted distribution and instructed us to create a new public app record and submit a new unlisted request using a new Apple ID. Following that guidance, we created a new public app record: App Name: FORTIS HRM Apple ID: 6785417374 We have submitted a new unlisted app distribution request and are currently waiting for review. Current Issue We feel stuck between all available distribution methods: Public distribution → rejected because app is internal-only ABM / Custom App → blocked due to organization verification failure Unlisted distribution → currently under review This has created a situation where no clear distribution path is available for our employee-only app. Request for Guidance We would appreciate guidance on the following: Has anyone experienced repeated ABM verification failures, and how was it resolved? Is there any recommended path for internal business apps when ABM is unavailable? Is there any way to ensure the App Review team understands the full context of this case? Request to App Review Team We respectfully request attention from the App Review team. This application has already been reviewed multiple times under different distribution paths. The app’s functionality remains essentially the same; only the distribution method has changed due to Apple’s requirements. This app was previously reviewed and approved by Apple under the custom app distribution path and marked ready for distribution. Since the core functionality remains unchanged, we kindly request consideration of this prior review history during the current review process. We would greatly appreciate any assistance in completing this review as efficiently as possible. Thank you for your time and support.

My app (RunWeather) is live on the App Store, but its two auto-renewable subscriptions have never reached Approved, so the StoreKit paywall returns no products and users can't subscribe. Subscriptions: com.iustinn.runweather.pro.monthly com.iustinn.runweather.pro.annual Both show "Pending Binary Approval". The English (U.S.) localization on each is stuck in "Rejected", and App Store Connect won't let me edit or delete that localization (the fields are locked), so I can't correct the copy and resubmit. I never received a clear reason for the localization rejection. History: each time I submitted a build with these subscriptions, the build was rejected for an unrelated reason; I resubmitted, the build was eventually approved, but the subscriptions stayed behind in this stuck state. I also created duplicate subscription products (…monthly2/3/4, …annual2/3/4) as a workaround; those just sit in "In Review" indefinitely. What I've tried: Editing / deleting the Rejected U.S. localization -> blocked, fields locked. Re-submitting builds -> app approved, subscriptions not. Questions: How do you unstick a subscription whose Rejected localization can't be edited or deleted? Is an App Review support ticket the only path to reset it? For "Pending Binary Approval" subscriptions, does attaching them to a NEW app version (reusing the existing build, no new binary) and submitting force them back through review? Has anyone cleared this exact locked-localization state another way? I've also opened an App Review case. Posting here in case someone hit the same locked-localization state. Thanks.

Hello, Our application connects to our backend server, which only allows access from specific IP addresses for security reasons. We understand that Apple owns the IP range 17.0.0.0/8, but we are unsure whether App Review traffic always originates from this range. Could you please clarify the following? Does App Review always access backend servers from IP addresses within 17.0.0.0/8? If so, is there a more specific IP range that can be allowlisted instead of the entire 17.0.0.0/8 block? If Apple does not provide a dedicated IP range for App Review, what is the recommended best practice for applications that restrict server access by IP address? Our goal is to minimize the allowlisted IP range while ensuring that App Review can successfully access our backend during the review process. Thank you for your guidance.

Hello, Our app has been in "Waiting for Review" status for more than a week, and our previous submission also took over a week to be reviewed. This delay is affecting our planned release schedule. App details: App name: Nhật Luân Kiếm App ID: 6777269196 We'd really appreciate any guidance on the current review timeline, or whether there is anything on our side we can do to help move the review forward. We're happy to provide any additional information if needed. Thank you very much for your time and support. Best regards.